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Previous large, multicenter NASA programs have been accomplished by dividing the program into 
elements ( e.g., command module, Saturn V booster ; Orbiter) that were designed, developed, and 
integrated by a prime contractor under the management of a single NASA center. While this method 
minimized the managerial complexity of a given program, it created an organizational structure unthin 
the agency that makes it difficult for new NASA programs to effectively use hardware and resources 
developed for previous programs. Therefore, each new NASA program must essentially start from scratch. 
In order to accelerate the movement of humans into space within reasonable budgetary constraints, 
NASA must develop an organizational structure that uill allow the agency to efficiently use all the 
resources it has available for the development of any program the nation decides to undertake. This 
work considers the entire set of tasks involved in the successful development of any program. Areas 
that hold the greatest promise of accelerating programmatic development and/or increasing the 
efficiency of the use of available resources by being dealt with in a centralized manner rather than 
being handled by each program individually are identified. Using this information, an agency 
organizational structure is developed that uiU allow NASA to promote interprogram synergisms. In order 
for NASA to efficiently manage its programs in a manner that will allow programs to benefit from 
one another and thereby accelerate the movement of humans into space, several steps must be taken. 
First, NASA must develop an organizational structure that will allow potential interprogram synergisms 
to be identified and promoted Key features of the organizational structure recommended in this paper 
include ( 1) the establishment of a single office to perform the mission analysis and system engineering 
functions across all NASA programs and, therefore, to replace the performance of these functions as 
part of each individual program; and (2) the establishment of technical discipline agents to perform 
subsystem management on an agency-wide basis, as opposed to hating each NASA center provide its 
own subsystem managers to support the development of those elements for which the center is 
responsible. Second, NASA must begin to develop the requirements for a program in a manner that 
will promote overall space program goals rather than achieving only the goals that apply to the program 
for which the requirements are being developed. Finally, NASA must consider organizing the agency 
around the functions required to support /VA£4’5 goals and objectives rather than around geographic 
locations. If lie are serious about moving toward the permanent presence and expansion of humans 
into space, AS4S4 must organize itself to be able to treat the space program as a program rather than 
as a collection of individual initiatives. 


During the early years of the Space Age, American endeavors 
in the area of manned spaceflight were generally accomplished 
through a series of relatively independent programs with fairly 
specific and well-defined goals. Often these programs were 
developed by dividing the program hardware into elements 
(usually, manned spacecraft elements and booster elements) that 
were designed, developed, and integrated by a single (prime) 
contractor under the management of a single NASA center. In 
1988 President Reagan announced a “Space Policy and Commer- 
cial Space Initiative to Begin the Next Century;’ which contained 
the following major components: ( 1 ) establishing a long-range 
goal to expand human presence and activity beyond Earth orbit 
into the solar system; (2) creating opportunities for U.S. com- 
merce in space; and (3) continuing our national commitment to 
a permanently manned space station. 

In order to accomplish the ambitious, broadly defined kinds of 
goals that this policy set for the nation, NASA must be capable 
of undertaking a variety of highly interactive and dynamic pro- 
grams with goals that will change and develop as each of these 


programs is defined and realized. Because the existing NASA 
organizational structure was developed to enable the agency to 
respond to programs of a specific, well-defined nature, it is 
desirable to review this structure in terms of its capability to 
respond to the kinds of challenges that NASA will be undertaking 
in order to fulfill the charges of the national space policy. This 
paper examines the organizational structure currently in existence 
for the implementation of NASA programs, and proposes an agen 
cy architecture structured to provide the flexibility NASA requires 
in order to efficiently accomplish the kinds of programs involved 
in the achievement of our national goals in space. 

Figure 1 presents an overview of the flow of the major functions 
involved in the development of a typical program. (For the sake 
of clarity, this flow is presented in a very basic and straightforward 
manner. The actual process, however, is highly interactive and 
iterative. ) The mission analysis function collects the necessary data 
and performs the analyses required to transform the top-level 
goals and constraints for the program into a set of quantified 
requirements that tells the engineers responsible for designing the 
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Fig. 1 . Overview of the flow' of a program. 


system, in specific terms, just what they are supposed to design 
the system to be able to do. The mission requirements, which 
are output as the product of the mission analysis activity, serve 
as an input to the system engineering function of the total system 
that defines the configuration of the most efficient (lowest total 
cost) system capable of meeting the performance parameters 
specified by the mission requirements. To “define” the configu- 
ration of the system means to determine and specify the elements 
that compose the system, along with the requirements on each 
of these elements. The word “element,” as used in this paper, 
refers to an essentially modular part of the total system in which 
the subsystems are relatively self-contained. Usually, though not 
always, this “modular, self-contained subsystems” property of an 
element is caused by the fact that the element functions as a 
separable, independent unit during some phase of the mission. 
The command module, the lunar module, the Saturn V booster, 
and the solid rocket boosters are all examples of elements. 
Although it does not separate during the mission, the main 
engines module of the space shuttle is also considered to be an 
element since it does fit this modular, self-contained subsystems 
definition. Additionally, this element is treated as an independent 
unit during processing. Under the above definition of an element, 
the mannedeore portion of the space station would be considered 
to be a single element that is divided into several subelements 
for development and assembly purposes. 

The element requirements output by the total system system 
engineering function serve as input for the element development 
phase of the program. During this phase, elements that meet the 
element requirements are developed. In the accomplishment of 
this activity, the following major functions are performed for each 
element of the program. 

1. Individual element system engineering that defines the 
configuration of the element that is most capable of meeting the 
requirements output by the total system system engineering func- 
tion; to “define” the configuration of an element means to de- 
termine and specify the requirements on each subsystem 
(including the element unique equipment, which is also treated 
as a subsystem during this analysis) of the element. 

2. Subsystems development that develops each subsystem in 
accordance with the subsystem requirements defined by the 
individual element system engineering function. 

3. Element integration that combines the developed subsys- 
tems into an element that meets the requirements levied on the 
element by the total system system engineering function. 


The final major function that must be performed in support of 
the development of a typical program is the system integration 
function, which combines the developed elements into a total 
system that meets the requirements levied on the system by the 
mission analysis function. 

To accomplish the earlier major, manned programs for which 
NASA was responsible, such as the Apollo and space shuttle 
programs, NASA, together with its Phase B contractors, performed 
the total system system engineering function, which defined the 
elements constituting the total system and produced a set of 
requirements on each of these elements. These requirements 
were then used to write the Phase C/D requests for proposal 
(RFPs) for the development of these elements. Generally, one 
contract was awarded for each of the elements to be developed. 
This contract included responsibility for the performance of all 
the functions involved in the development of the element: the 
system engineering function that defined the requirements on the 
subsystems of the element (note that here the “system referred 
to in the system engineering function is the element), the de- 
velopment of all the subsystems of the element, and the 
integration of these subsystems into an element. In addition to 
the element contracts, an integration contract (or a separate 
schedule) was awarded for the integration of the developed 
elements into a total system. This integration contract did not 
include any responsibility for the integration of an element s 
subsystems into the element. This type of element integration was 
handled as part of the contract for the development of each 
element. 

The development contract for each element of a program was 
managed by a single NASA center. Additionally, each element of 
the earlier major, manned NASA programs could generally be re- 
lated to some major function— propulsion, crew support (manned 
spacecraft), communications, or operations— required for the ac- 
complishment of the program. For the Apollo program, as shown 
in Fig. 2a, centers were set up to provide expertise in these areas. 
Because the space shuttle was composed of dements with these 
same functions, the space shuttle program could be smoothly 
managed using the same structure that the agency developed in 
order to accomplish the Apollo program (Fig. 2b). 

With the undertaking of the space station program, NASA as- 
sumed responsibility for the development of a program that could 
not be divided into a set of Apollo-like dements. In fact, as Fig. 3 
illustrates, by the modular, self-contained subsystems definition of 
an element, the mannedeore space station is really a single ele- 
ment that has been divided into several subelements for 
development and assembly purposes. Since, in the case of the 
mannedeore space station, the dement equals the total system, 
only the “inner loop” functions shown in Fig. 1, those associated 
with the development of a single element, are performed for the 
mannedeore element of the space station program. In order to 
handle this situation, NASA had to chtxise between awarding a 
single contract for all the functions— system engineering, sub- 
systems development, and element integration — involved in the 
development of the mannedeore space station element, or 
changing the architecture of the agency enough to enable NASA 
itself to assume responsibility for the performance of these fime 
tions. The first option would allow NASA to develop the man- 
nedcore space station dement using the same programmatic 
methodologies the agency already has in place as a result of sup 
porting its past programs; the second would incorporate some of 
the element development procedures formerly performed by the 
prime contractor for an dement and would force NASA to manage 
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Fig. 3. Today’s programs: A new way of doing business. 
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Fig. 2. (a) In the beginning: The Apollo program, (b) Continuing the 

tradition: The space shuttle program. 


the contracts for the accomplishment of some of the specific 
activities (such as the development of a particular subsystem) 
involved in the development of an individual element. Previously, 
under the single contract method, the prime contractor for the 
element awarded and managed subcontracts for the performance 
of these element development tasks. 

As NASA undertakes the programs required for the achievement 
of our national goals in space, it will assume responsibility for the 
development of many different types of aerospace systems— cargo 
and personnel transports, spaceports, surface habitats of both a 
temporary and a permanent nature, mining facilities, and so 
forth— that may not easily divide into manned spacecraft and 
booster-type elements for development purposes. In fact, as has 
already been illustrated, some systems may not efficiently divide 
into elements at all. In order to meet the challenges of the future, 
NASA will require an agency architecture that is flexible enough 
to support the development of a large variety of different types 
of aerospace elements. 


Additionally, each major, manned program undertaken by NASA 
has been the focus of attention of the agency for the duration 
of the program and has usually been completed before the de- 
velopment of the next major program was begun. Because past 
programs had fairly specific goals, each program could generally 
be structured as a means to the accomplishment of a limited set 
of objectives that terminated (or passed over from a development 
to an operational phase) when this set of objectives was achieved. 
For this reason, previous NASA programs were accomplished rel- 
atively independently of one another. The most notable excep- 
tions occur in programs such as Apollo-Colo3 and Sky lab that 
used hardware from a previous program. Even these programs, 
however, are simply cases of making use of already existing hard 
ware rather than being examples of any type of "global” planning 
across several programs. (That is, the hardware was custom 
designed for the initial program. Later programs were then 
“forced-fit” to be able to make use of this existing hardware 
instead of designing the initial hardware to be the optimum 
hardware for all the programs that were expected to use it.) 

In order to accomplish the broad, long-range kinds of goals 
specified by the national space policy, NASA will have to define, 
develop, and undertake sets of highly interactive programs that 
together achieve a high-level goal. As illustrated in Fig. 4, a lunar 
colony may consist of lunar science facilities, observation 
equipment for studying the universe, and a LOX facility that will 
provide propellants for transports to Mars. Although this colony 
is composed of elements that are satisfying the objectives of three 
different programs, it may be beneficial to design the colony so 
that the crew members supporting these elements all share the 
same habitat (and the same logistics support) and so that the 
elements all receive their power from the same power facility. 
Though developed under a number of different programs, the 
entire set of elements shown in the figure efficiently achieve the 
goal stated in the national space policy of “establishing a long 
range goal to expand human presence and activity beyond Earth 
orbit and into the solar system.” In order for the entire colony 
to function smoothly, all the elements of the lunar colony would 
have to be designed to “play together” as components of a single 
system. Additionally, the elements of this lunar colony would have 
to be capable of smoothly interfacing with the elements of the 
programs of which they are a part; i.e., the lunar observatories 
may have to coordinate with other Earth- or space-based 
equipment in order to provide complete data required for a 
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Fig. 4. The interactive nature of potential future programs. 


particular astronomy experiment, the IjOX facility will have to 
function in cooperation with the Mars transport vehicles for 
which it provides propellants, the entire colony must be able to 
interface with its resupply and logistics support network, and so 
forth. If NASA plans to undertake this type of ambitious scenario 
in the future, it will be necessary for the agency to develop the 
capability to define the requirements for each of its new programs 
in a manner that enables these programs to efficiently interact 
with the other agency programs and thereby promotes the overall 
goals of the space program rather than in a manner that will 
achieve only the goals of the individual program for which the 
requirements are being defined. 

In summary, in order to achieve the goals that the U. S. has 
set for itself in space, NASA will require an architecture that 
enables the agency to: ( 1 ) develop the requirements on the 
elements of future agency programs in a manner that recognizes 
and accounts for the interactions that need to take place in order 
for the elements of these programs to function together as part 
of a single, coordinated, space program; and (2) handle the de- 
velopment of a variety of different types of elements. 

In past programs, the system under development was optimized 
to achieve a set of mission requirements that were specific to the 
program itself. Any interactions with other programs could 
generally be handled as external interfaces with already developed 
systems (thereby making these interfaces very specific; such 
interfaces could generally be handled as being constraints on the 
program). Anticipated interactions, or optimum trade-offs, with 
elements of projected future systems were rarely considered. 
Instead, when such future programs did reach the development 
stage, they would handle any necessary interactions with the 
previous program as being constraints on the new program. This 
situation meant that a system could be defined by considering 
only those interactions taking place between the elements of the 
system itself. If, however, NASA now plans to begin serious 
consideration of the interactive types of programs required for the 
achievement of the ambitious kinds of goals specified in the 
national space policy, it will be necessary to consider the 
interactions and optimum trade-offs occurring between the 
elements of a number of systems that will be developed at 
different times under different programs. This new set of 
circumstances suggests that those functions leading to the 
definition of the elements of a given program— the mission 
analysis and total system system engineering functions (refer to 
Fig. 1 )— should be replaced by a function that analyzes the 


interactions and optimizes the trade-offs between the elements of 
all the programs (or potential programs) that make up the 
nation’s space program. This situation, illustrated in Fig. 5, implies 
that NASA should consider replacing the mission analysis and total 
system system engineering functions previously performed as part 
of each individual agency program with a single “program 
engineering” (where “program” here refers to the whole space 
program) function that serves the entire agency. An agency 
program engineering office should be set up to implement this 
function. 

Although an explanation of the program engineering process 
is beyond the scope of this paper, a few points should be 
mentioned The program engineering process is basically a system 
engineering process in which the “system” under analysis is the 
entire space program. Beginning with broad categories of missions 
that offer the potential for furthering our national goals in space 
(for example, perform a thorough scientific study of the Moon, 
study the universe beyond our solar system, perform a thorough 
scientific study of Mars, and so forth), the specific experiments 
and processes (or candidate options for experiments and 
processes) required for the accomplishment of each mission 
category are identified. The mission analyses and system 
engineering studies required to accomplish this set of experi- 
ments and processes are performed in such a manner that any 
synergies and beneficial trade-offs between these mission activities 
and the systems designed to support their implementation are 
identified. (The program engineering process would identify, for 
example, that some of the equipment used to perform observa- 
tions of the universe can, or should be, lunar-based, and that the 
crew members required to operate and maintain this equipment 
could share a habitat with lunar crew members performing lunar 
science experiments and those operating a LOX facility producing 
propellants for transports to Mars. The number, character 
(content or “set of elements”), and time-phasing of the most 
efficient set of programs leading to the accomplishment of the 
complete set of input mission categories is produced as an output 
of the program engineering process. Notice the “crossovers" that 
occur between input missions and the programs in which these 
missions are actually implemented. (Some of the observation 
equipment used to support the Study' of the Universe mission 
category may be developed as part of a lunar program, and other 
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Fig. 5. NASA program development process. 
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equipment supporting such a mission may end up being 
developed as part of a low-Earth-orbit program; the LOX facility, 
though supporting a Mars mission, may itself be developed as part 
of a lunar program; and so forth.) Another important point that 
should be mentioned in regard to the program engineering 
process is that, although this process should be the responsibility 
of a single office (the agency program engineering office), it is 
not expected that all the personnel needed to perform this proc- 
ess would be located in that office. The agency program engi- 
neering office itself should direct and coordinate the studies and 
analyses required for the performance of the program engineering 
process and should interpret the results leading to the definition 
of the elements (and programs) needed to accomplish our 
national goals in space. The actual performance of the studies and 
analyses required to support the program engineering process 
should be performed by the NASA institution located at the field 
centers. 

Although the establishment of an agency program engineering 
office for the performance of the program engineering function 
will enable NASA to define the elements of its programs in a 
manner that optimizes the interactions between these elements, 
the problem of determining an organizational structure that will 
allow the agency to efficiently develop any type of element defined 
as an output of this process still remains. Figure 6 suggests a 
solution to this situation by pointing out that all the elements 
defined by the total system system engineering function (or by 
the program engineering function that replaces it in the case of 
highly interactive programs) are basically composed of the same 
kinds (though not necessarily the same architecture) of sub- 
systems. 

As Fig. 7a illustrates, in managing the development of the 
elements of past programs, NASA used subsystem managers who 
were located at the same center as the project office for the 
element they supported and who developed expertise in the types 
of subsystems associated with that element. This meant that each 
center developed a pool of experts who were adept at under- 
standing a particular set of subsystem architectures associated 
with the elements that had been developed at that center. During 
the Apollo program, which had the unique opportunity of 
structuring the agency to meet its needs (see Fig. 2a), and the 
space shuttle program, which resembled the Apollo program in 
terms of programmatic structure (see Fig. 2b), this subsystem 
manager arrangement worked well. However, as NASA moves 
toward a future that envisions expansions into new areas of space 
exploration and begins the undertaking of the programs required 
for the realization of this vision, it is very likely that the current 
approach to programs in which almost all the personnel 
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Fig. 7. Use of technical discipline agents for consolidation of subsystem 
management: (a) Existing subsystem management structure in which each 
center provides its own subsystem managers for every subsystem of the 
element(s) for which the center is responsible; (b) proposed subsystem 
management structure in which, for a given subsystem, the same technical 
discipline agent provides subsystem management for all elements in the 
agency. 


(including the subsystem managers) associated with the 
development of an element work directly for the center respon- 
sible for the element will prove to be too inflexible to allow NASA 
to efficiently manage the variety of new programs the agency will 
be undertaking in the near future. One of the problems likely to 
be encountered in the future is the need to reassign personnel 
and to redirect the use of facilities that were involved in the 
development of a program after the program moved into its 
operational stage. This problem becomes especially acute when 
the center is not assigned responsibility for the development of 
a new element (which is one of the motivations behind the 
competition between centers that is sometimes observed during 
the assignment of the elements of a new program). Another 
problem that may be encountered is an unnecessary duplication 
of effort between different centers caused by the fact that, under 
the current NASA organizational structure, it is easier for a center 
to establish its own expertise in a particular technical discipline 
than it is to access already established expertise located at another 
center. Yet another potential problem is the probability of mis- 
matches occurring between center expertise and the assignment 
of the development of an element to a particular center. Such 
mismatches are caused by the fact that in the past, when NASA 
assigned the development of an element to a center, this assign- 
ment included the development of all the subsystems within the 
element, even if the expertise in some of the subsystems was 
located at another center. As NASA begins to assume responsibility 
for the development of a large variety of elements, a situation 
develops in which the expertise in some of the subsystems of an 
element will be located at one center, while the expertise in other 
subsystems will be located at other centers. NASA must then solve 
how to assign the development of the element to a particular 
center while efficiently making use of all the center expertise, 
with its associated resources (test beds, research facilities, 
databases, and so forth) available throughout the agency. As 
Fig. 7b illustrates, one method of alleviating this situation is by 
establishing a technical discipline agent for each of the subsystems 
involved in the development of a typical aerospace element. These 





688 2nd Conference on Lunar Bases and Space Activities 


agents are groups (possibly divisions or small directorates) of 
technical personnel set up to provide support in their technical 
discipline to any NASA program requiring such support, regardless 
of where the program or project office requiring the support was 
located. (In order to maximize the effectiveness of technical 
discipline agents, it is recommended that NASA investigate the 
feasibility of standardizing the types, though not the architectures, 
of subsystems associated with the development of any given 
element.) By eliminating the need for each technical discipline 
agent to be located at the same center as the office it supports, 
technical discipline agents offer one potential method for 
providing NASA with the flexibility it requires to support a variety 
of new programs. As one program ends or scales down for a 
period of time, the manager of a technical discipline agent can 
reassign the personnel who were supporting the program to new 
programs just beginning to require support. Such reassignments 
can be made regardless of where the project offices for the new 
program are located. 

The establishment of an agency program engineering office and 
technical discipline agents are suggested as methods for the 
solution of specific problems expected to be encountered as the 
agency begins undertaking the kinds of programs involved in the 
achievement of our future national goals in space. Still remaining 
is the consideration of an organizational structure, with its asso- 
ciated lines of authority or management structure, which 
combines these concepts with the other functions required for 
the successful accomplishment of a program in a manner flexible 
enough to accommodate the development of any set of programs 
that the nation decides to undertake in space. Figure 8a illustrates 
the current NASA organizational structure in which all employees 
located at a given center, including those in any program or proj- 
ect office located at the center, are under the direct management 
of the director of the center. Each center is, in turn, under the 
management of a specific code. During the Apollo program, when 
centers were established to provide specific functions in support 
of the development of the program, and these functions were 
consistent with the responsibilities of the code that managed the 
center, such an organizational structure worked well; that is, the 
organizational structure was consistent with the structure of the 
program it was managing. Since the Apollo program, however, 
NASA has managed the development of an ever-increasing variety 
of programs. Taking on new kinds of programs without modifying 
the structure of the agency to be consistent with the needs of 
these new programs has left NASA with a structure that possesses 
significant gaps and inconsistencies in some of the lines of 
communication and authority involved in the implementation of 
its programs. For example, during Phase B of the space station 
program, the program manager did not answer directly to the 
associate administrator for the space station program (CodeS). 
Instead, the program manager answered to the center director 
of the center at which the program office was located (the 
Johnson Space Center, in this case), who, in turn, answered to 
the associate administrator for manned spaceflight (Code M). The 
associate administrator for manned spaceflight and the associate 
administrator for the space station program were organizational 
equals, both of whom answered to the administrator. Similarly, 
there were no direct lines of communication between the 
program manager and the projects office managers for each of 
the work packages of the space station program. Each projects 
manager answers to the director of the center at which the 
projects office is located who, in turn, answers to the associate 
administrator of the code responsible for that center. Today, 
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Fig. 8 . (a) Existing NASA organizational structure; (b) proposed NASA 
organizational structure. 


although the program manager (now called the program director) 
has been moved to the office of the associate administrator for 
the space station program, the lines of authority directing projects 
managers are still somewhat unclear. There are several similar 
situations throughout the agency in which personnel involved in 
the accomplishment of a program, which is the development 
responsibility of one code, work for a center managed by another 
code. The lines of authority in these cases are often somewhat 
ambiguous. This situation will certainly affect the agency's ability 
to efficiently manage the programs it will be undertaking in the 
future. 

In order to provide more direct lines of authority between the 
agents involved in the implementation of future programs, this 
paper suggests that NASA consider employing an organizational 
structure like that illustrated in Fig. 8b. Under the arrangement 
shown in this figure, a program is developed through the Phase B 
level (that is, through to the determination of the requirements 
on the elements of the program) by the agency program 
engineering office, which is part of its own code, separate from 
the other NASA codes. Upon authorization of a particular program, 
responsibility for the program is handed off to the code that has 
been assigned responsibility for the development of the program. 
For example, responsibility for the development of an unmanned 
planetary exploration program may be handed off to Code E, 
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responsibility for the development of a manned program may be 
handed off to Code M, responsibility for the development of an 
especially large program may be handed off to a new code created 
for the management of its development (like the space station 
program), and so forth. Upon authorization of a particular 
program, the responsible code sets up a program office to manage 
the development of the overall program and a project office for 
each element of the program to manage the development of its 
respective element. Regardless of the location of each program 
or project office, all the personnel in the office answer directly 
to the program manager who, in turn, answers directly to the as- 
sociate administrator of the code responsible for the development 
of the program. That is, all personnel in the program- related 
offices are badged to the NASA code responsible for the devel- 
opment of the program. (This situation is somewhat analogous 
to that employed by the Air Force in which all personnel under 
a particular Command are considered to be pan of that Command 
regardless of the base at which they are physically stationed.) 
Additionally, Fig. 8b recommends the establishment of a new code 
to be responsible for the management of the facilities of all the 
centers in the agency. All centers would be managed by this code 
(i.e., all center directors would be under the authority of the as- 
sociate administrator for this code), which, through its center 
directors, would be responsible for insuring that the personnel 
located at each center were provided with the proper resources 
and support required to accomplish their job, no matter which 
agency code they were attached to. Additionally, any personnel 
who were specific to the center, like the technical discipline 
agents located at the center, would be under the managerial au- 
thority of the center director who, in turn, would be under the 
authority of the associate administrator for the center manage- 
ment code. The technical discipline agents would provide tech- 
nical support in their disciplines to all NASA program and project 


offices as well as to the agency program engineering office on 
a “contract for services required” basis. These technical discipline 
agents would provide the services previously performed by the 
subsystem managers in past NASA programs, as well as the support 
the agency program engineering office and the project offices will 
require in order to perform the program engineering and contract 
management functions for which they are responsible. 

In conclusion, this paper attempts to provide a strawman 
architecture that addresses some of the new kinds of problems 
with which NASA will most likely be expected to have to deal 
as it undertakes the ambitious types of programs suggested by our 
national space policy. This proposed architecture has been devel- 
oped by primarily concentrating on concerns that are specific to 
the successful development of NASA programs. In undertaking the 
development of a complete architecture for the agency, NASA will 
have to determine how the development of the programs for 
which the agency is responsible fits into the complete set of 
activities with which NASA is concerned. Any architecture 
adopted by the agency should, as a minimum, however, enable 
it to ( 1 ) determine the requirements on the elements of future 
agency programs in a manner that accounts for the interactive 
nature of these programs, and (2) assign the development of any 
type of program element to the various factions of the agency that 
will be involved in this development in a manner that efficiently 
uses all the resources available to the agency. Finally, it is 
recommended that NASA thoroughly review any organizational 
structure that the agency considers adopting to insure that the 
structure is complete and consistent. A collection of isolated 
solutions to the individual problems encountered as NASA takes 
on the challenges of the future will not be sufficient to see it 
through the development and operation of the large-scale, highly 
interactive kinds of programs for which it will be responsible as 
we move into the next century . 




